X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C93536.5AAC3357@onstor-exch02.onstor.net>; Thu, 23 Oct 2008 10:39:52 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C93536.5AAC3357"
Content-class: urn:content-classes:message
Subject: RE: Lun Label type-5 Functional Spec. for Kegg
Date: Thu, 23 Oct 2008 10:39:51 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E0C19C93A@onstor-exch02.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E038F913E@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Lun Label type-5 Functional Spec. for Kegg
Thread-Index: Ack0pDOGwsjJ1gNkTEyXhNf4IHF7KQAiul2wAAEHxdAAAFt/oAAAU/bA
References: <BB375AF679D4A34E9CA8DFA650E2B04E038F913D@onstor-exch02.onstor.net> <BB375AF679D4A34E9CA8DFA650E2B04E038F913E@onstor-exch02.onstor.net>
From: "Dave Limato" <dave.limato@onstor.com>
To: "James Kahn" <james.kahn@onstor.com>,
	"dl-Design Review" <dl-designreview@onstor.com>
Cc: "dl-Kegg" <dl-Kegg@onstor.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C93536.5AAC3357
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Got it. Maybe we simply need to make it clear in section 2.1.2 that we
won't be able to claim the space of the expanded lun. That that is a
feature to come later, (section 2.3).

> _____________________________________________=20
> From: 	James Kahn =20
> Sent:	Thursday, October 23, 2008 10:34 AM
> To:	Dave Limato; dl-Design Review
> Cc:	dl-Kegg
> Subject:	RE: Lun Label type-5 Functional Spec. for Kegg
>=20
> Hi Jim, Nice work. Here are my comments.
>=20
> Pg 7 2.3.3	Is the scsi id the only way vendors identify mirrors? Or
> will you match the label, and if the id is different, don't use it.
>=20
> SCSI ID is matched against the label SCSI ID.  If they match, then
> it's the source volume LUN.  If not, it would be
> Assumed to be the mirror.  That's the easy part.  Then you need some
> way to promote the physical mirror, etc.
> So, the plan is to do physical mirror functional spec. to define the
> requirements.
>=20
> Pg 7 2.3.4	I understand single lun volumes growing by expansion.
> But taking a storage volume that has been expanded, which already
> belongs to an ONStor volume, and using extents that are free to serve
> other ONStor volumes seems un manageable. and difficult to track for
> the storage admin. Unless our volumes only manage and use free
> extents, how will this work? How will you manage a volume that becomes
> comprised of luns and free extents?=20
>=20
> For starters, you restrict operations to be on the vsvr.  LUN
> discovery would be done in two parts.  First part discovers
> The LUN.  Second part binds the LUN extents to the volume.  Volume
> create/modify would have to be more complex.
> However, that is for a future functional spec.  A LUN just contains 1
> extent with at most one volume at this stage.
>=20
> Pg 12 5.3	Congratulations, you saved memory!
>=20
> Pg 17 5.4.4	If the LUN was part of a volume before being expanded,
> the volume will not have access to the expanded capacity of the LUN.
> Doesn't that defeat the purpose of expanding the lun? What will we do
> now that the lun has been expanded?=20
>=20
> Currently, if a LUN is expanded, the volume label is lost with the net
> effect the volume is gone.
> The intent at this stage is to be unaffected by LUN expansion.  The
> legacy and alternate label
> are simply moved to the new LUN.  The labels are updated with the new
> capacity.
>=20
> For the next functional spec, the volume would then get the expanded
> capacity.  That would require
> the volume grow operation to be updated to grow by free extents.  Then
> you need knobs to register
> HOW a volume should be grown.
>=20
> For this spec, the requirement was simply not to kill the volume if
> the LUN is expanded.
>=20
> Note, the comment in the road map section that this is the FIRST of a
> series.
> So, rather than having one GIANT functional spec., I'm going for a
> series of smaller
> focused functional specs.
>=20
> Regards,
> Jim
>=20
> _____________________________________________=20
> From: 	James Kahn =20
> Sent:	Wednesday, October 22, 2008 5:14 PM
> To:	dl-Design Review
> Cc:	dl-Kegg
> Subject:	Lun Label type-5 Functional Spec. for Kegg
>=20
> Here's lun label functional spec. updated for Kegg for review.
> Regards,
> Jim
>=20
>=20
> <\\mightydog\software\kegg\functional specs\lunLabel1.doc>
>=20
>=20

------_=_NextPart_001_01C93536.5AAC3357
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: Lun Label type-5 Functional Spec. for Kegg</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Got it. Maybe we =
simply need to make it clear in section 2.1.2 that we won't be able to =
claim the space of the expanded lun. That that is a feature to come =
later, (section 2.3).</FONT></P>

<P><FONT SIZE=3D1 =
FACE=3D"Tahoma">_____________________________________________ </FONT>

<BR><B><FONT SIZE=3D1 FACE=3D"Tahoma">From: &nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Tahoma">James Kahn&nbsp; </FONT>

<BR><B><FONT SIZE=3D1 FACE=3D"Tahoma">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Tahoma">Thursday, October 23, 2008 10:34 AM</FONT>

<BR><B><FONT SIZE=3D1 =
FACE=3D"Tahoma">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Tahoma">Dave Limato; dl-Design Review</FONT>

<BR><B><FONT SIZE=3D1 =
FACE=3D"Tahoma">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Tahoma">dl-Kegg</FONT>

<BR><B><FONT SIZE=3D1 =
FACE=3D"Tahoma">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Tahoma">RE: Lun Label type-5 Functional =
Spec. for Kegg</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Hi Jim, Nice work. =
Here are my comments.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Pg 7 =
2.3.3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Is the scsi id the only way vendors =
identify mirrors? Or will you match the label, and if the id is =
different, don't use it.</FONT></P>

<P><FONT COLOR=3D"#3366FF" SIZE=3D2 FACE=3D"Arial">SCSI ID is matched =
against the label SCSI ID.&nbsp; If they match, then it&#8217;s the =
source volume LUN.&nbsp; If not, it would be</FONT>

<BR><FONT COLOR=3D"#3366FF" SIZE=3D2 FACE=3D"Arial">Assumed to be the =
mirror.&nbsp; That&#8217;s the easy part.&nbsp; Then you need some way =
to promote the physical mirror, etc.</FONT>

<BR><FONT COLOR=3D"#3366FF" SIZE=3D2 FACE=3D"Arial">So, the plan is to =
do physical mirror functional spec. to define the requirements.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Pg 7 =
2.3.4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I understand single lun volumes =
growing by expansion. But taking a storage volume that has been =
expanded, which already belongs to an ONStor volume, and using extents =
that are free to serve other ONStor volumes seems un manageable. and =
difficult to track for the storage admin. Unless our volumes only manage =
and use free extents, how will this work? How will you manage a volume =
that becomes comprised of luns and free extents? </FONT></P>

<P><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">For starters, you =
restrict operations to be on the vsvr.&nbsp; LUN discovery would be done =
in two parts.&nbsp; First part discovers</FONT></P>

<P><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">The LUN.&nbsp; Second =
part binds the LUN extents to the volume.&nbsp; Volume create/modify =
would have to be more complex.</FONT>

<BR><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">However, that is for =
a future functional spec.&nbsp; A LUN just contains 1 extent with at =
most one volume at this stage.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Pg 12 =
5.3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Congratulations, you saved =
memory!</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Pg 17 =
5.4.4&nbsp;&nbsp;&nbsp;&nbsp; If the LUN was part of a volume before =
being expanded, the volume will not have access to the expanded capacity =
of the LUN. Doesn't that defeat the purpose of expanding the lun? What =
will we do now that the lun has been expanded? </FONT></P>

<P><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">Currently, if a LUN =
is expanded, the volume label is lost with the net effect the volume is =
gone.</FONT>

<BR><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">The intent at this =
stage is to be unaffected by LUN expansion.&nbsp; The legacy and =
alternate label<BR>
are simply moved to the new LUN.&nbsp; The labels are updated with the =
new capacity.</FONT>
</P>

<P><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">For the next =
functional spec, the volume would then get the expanded capacity.&nbsp; =
That would require<BR>
the volume grow operation to be updated to grow by free extents.&nbsp; =
Then you need knobs to register<BR>
HOW a volume should be grown.</FONT>
</P>

<P><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">For this spec, the =
requirement was simply not to kill the volume if the LUN is =
expanded.</FONT>
</P>

<P><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">Note, the comment in =
the road map section that this is the FIRST of a series.</FONT>

<BR><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">So, rather than =
having one GIANT functional spec., I&#8217;m going for a series of =
smaller<BR>
focused functional specs.</FONT>
</P>

<P><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">Regards,</FONT>

<BR><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">Jim</FONT>
</P>

<P><FONT SIZE=3D1 =
FACE=3D"Tahoma">_____________________________________________ </FONT>

<BR><B><FONT SIZE=3D1 FACE=3D"Tahoma">From: &nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Tahoma">James Kahn&nbsp; </FONT>

<BR><B><FONT SIZE=3D1 FACE=3D"Tahoma">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Tahoma">Wednesday, October 22, 2008 5:14 PM</FONT>

<BR><B><FONT SIZE=3D1 =
FACE=3D"Tahoma">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Tahoma">dl-Design Review</FONT>

<BR><B><FONT SIZE=3D1 =
FACE=3D"Tahoma">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Tahoma">dl-Kegg</FONT>

<BR><B><FONT SIZE=3D1 =
FACE=3D"Tahoma">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Tahoma">Lun Label type-5 Functional Spec. =
for Kegg</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Here&#8217;s lun label functional spec. =
updated for Kegg for review.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Regards,</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Jim</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">&lt;</FONT><A =
HREF=3D"file://\\mightydog\software\kegg\functional =
specs\lunLabel1.doc"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">\\mightydog\software\kegg\functional =
specs\lunLabel1.doc</FONT></U></A><FONT FACE=3D"Times New =
Roman">&gt;</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C93536.5AAC3357--
